바이브 코딩 도구를 쓰기 시작한 뒤, 왜 우리는 더 피곤해지는가?! | 매거진에 참여하세요

처음 AI 코딩 도구를 제대로 쓰기 시작했을 때를 떠올려보면, 솔직히 좀 흥분됐을 거다.
코드가 자동으로 채워지고, 귀찮던 보일러플레이트가 순식간에 사라지고, 예전 같으면 문서 뒤지며 한참 고민했을 부분이 몇 초 만에 해결되는 경험.

“이제 진짜 개발이 쉬워지는구나”라는 생각이 들었다.

그런데 어느 순간부터 묘한 감각이 들기 시작한다.
분명 예전보다 코드는 빨리 짜고 있다. 커밋 수도 늘었고, 기능도 더 빨리 나간다. 그런데 이상하게도 하루가 끝나면 예전보다 더 지쳐 있다.

코드 리뷰는 더 오래 걸리고, 장애는 줄지 않고, ‘내가 지금 뭘 만들고 있는지’ 흐릿해지는 순간이 늘어난다.

이게 개인의 착각일까?
아니면 AI 코딩 도구가 개발의 어떤 균형을 살짝 깨뜨린 걸까.

이제 AI는 코드를 대신 써준다.

이 문장은 이제 너무 당연해서 새로울 것도 없다. 하지만 우리가 놓치고 있는 건, AI는 코드를 “이해”하지 않는다는 사실이다.

더 정확히 말하면, 이해할 필요가 없다. 입력과 출력 사이에서 가장 그럴듯한 답을 만들어내는 게 목적이기 때문이다.

문제는 사람이 그 코드 위에 서서 살아야 한다는 점이다.

예전에는 코드의 흐름이 어느 정도는 몸에 남았다. 직접 타이핑하고, 에러를 맞고, 고치고, 다시 깨지면서 “아, 이건 이렇게 돌아가는구나”라는 감각이 축적됐다.

지금은 그 과정이 짧아졌다. 너무 짧아졌다. 어떤 경우에는 아예 생략된다.

“일단 돌아가니까” , “AI가 추천한 코드니까”
이 두 문장이 팀 대화에서 자주 나오기 시작했다면, 이미 변화는 시작된 거다.

AI가 만든 코드의 가장 큰 특징은 설명이 없다는 것이다.

주석이 없다는 얘기가 아니다. 구조 자체가 “왜 이렇게 설계됐는지”를 말해주지 않는다.

동작은 한다. 테스트도 통과한다. 그런데 질문을 던지면, 대답이 막힌다.

“이 분기문은 왜 여기 있는 거야?”
“이 캐시는 어떤 상황을 가정한 거지?”
“이 비동기 처리는 굳이 이 타이밍이어야 했어?”

이 질문에 답할 수 없다면, 그 코드는 사실상 팀의 자산이 아니다.

그저 잠시 작동하고 있는 블랙박스에 가깝다. 문제는 이런 블랙박스가 AI를 통해 아주 빠르게 늘어난다는 점이다.

처음엔 생산성이 올라간 것처럼 보인다. 하

지만 시간이 지나면, 코드베이스 전체가 “아무도 완전히 이해하지 못하는 상태”로 변해간다. 그때부터 개발은 느려진다. 무섭게 느려진다.

탁월한 코드도 점점 사라진다

또 하나 이상한 변화가 있다. 코드의 평균 품질이 눈에 띄게 나빠진 건 아닌데, 탁월한 코드도 점점 사라진다는 느낌이다.

AI가 추천하는 코드는 대체로 무난하다. 인터넷 어딘가에서 많이 쓰였고, 문법적으로 안전하고, 큰 사고를 내지는 않는다.

문제는 ‘우리 팀에 딱 맞는 코드’가 아니라는 점이다.

AI는 우리 서비스의 과거 장애를 모른다. 왜 특정 부분에서 유난히 보수적으로 코드를 짜왔는지, 어떤 선택이 수년간의 트레이드오프 끝에 내려진 건지 알지 못한다.

그 맥락이 빠진 상태에서 제안되는 코드는, 결국 어디에도 날카롭지 않은 중간값으로 수렴한다.

이건 당장엔 편하다. 하지만 장기적으로는 팀의 기술적 개성이 사라진다. 코드베이스가 “그럴듯한 예제 모음”처럼 변해간다.

그리고 이 상태에서 시스템은 아주 천천히, 그러나 확실하게 복잡해진다.

의도를 추리해야 하는 상황이 늘어나고 있다.

많은 사람들이 AI 덕분에 코드 리뷰가 쉬워질 거라고 기대했다. 하지만 실제로는 반대 경험을 하는 팀이 꽤 많다.

이유는 단순하다. 리뷰어가 이제 코드의 품질만 보는 게 아니라, 의도를 추리해야 하는 상황이 늘어났기 때문이다.

AI가 만든 코드는 종종 필요 이상으로 길고, 추상화가 과하고, 문제를 직접적으로 드러내지 않는다.

리뷰를 하다 보면 이런 생각이 든다.

“이걸 이렇게까지 감쌀 이유가 있었을까?”
“혹시 이 부분에서 놓친 케이스는 없을까?”

리뷰는 점점 ‘검증’이 아니라 ‘탐색’이 된다.

이 코드가 안전한지 판단하려면, 내가 먼저 이 코드를 다시 이해해야 한다.

결과적으로 작성 시간은 줄었는데, 이해 시간은 늘어났다. 이건 명백한 역전이다.

테스트 코드도 뭔가 이상하다.

테스트 코드도 비슷하다. AI는 테스트 코드를 정말 잘 만들어준다. 보기에도 깔끔하고, 패턴도 익숙하다.

그런데 이상하게도, 그런 테스트들이 있는 서비스에서 사고가 난다.

왜일까.

AI가 만들어주는 테스트는 대부분 “정상적인 흐름”을 잘 검증한다.

하지만 실제 장애는 늘 이상한 곳에서 터진다. 엣지 케이스, 예상하지 못한 입력, 타이밍 문제, 혹은 사람이 절대 이렇게 쓰지 않을 거라 가정했던 행동에서.

이건 AI의 잘못이 아니다. AI는 사고를 겪어보지 못했기 때문이다.

테스트는 결국 과거의 실패 경험에서 나온다. 이 경험을 건너뛰면, 테스트의 수는 늘어나도 안전성은 크게 올라가지 않는다.

이쯤 되면 이런 질문이 떠오른다.

“그럼 AI는 누구에게 더 위험할까?”

의외로, 주니어 개발자다.

AI는 주니어를 빠르게 ‘일할 수 있는 상태’로 만들어준다. 그런데 그 과정에서 중요한 걸 빼앗아 간다.

막히는 경험, 헤매는 시간, 직접 원인을 찾는 감각. 이게 쌓이지 않으면, 문제 해결 능력은 자라지 않는다.

AI가 없으면 아무것도 못 하는 상태. 이건 과장이 아니다. 실제로 장애 상황에서 로그를 보며 손이 멈추는 개발자들이 늘어나고 있다. 평

소엔 AI가 대신 생각해주었기 때문이다.

결국 이 모든 문제는 하나로 수렴한다.
AI는 책임을 지지 않는다.

코드가 깨졌을 때, 서버가 죽었을 때, 새벽에 호출을 받았을 때 AI는 나타나지 않는다. 그 자리에 있는 건 사람이다.

그리고 그 사람이 “왜 이렇게 만들어졌는지”를 모른다면, 문제는 배로 커진다.

그래서 이 글의 결론은, AI를 쓰지 말자는 이야기가 아니다. 오히려 반대다. AI는 이제 너무 강력해서, 안 쓰는 게 비현실적이다.

다만 기준이 필요하다.

• - 이 코드를 이해하지 못한 채 머지해도 되는가?
  - AI가 제안한 구조를 그대로 받아들일 것인가, 아니면 질문을 던질 것인가?
  - 속도를 얻는 대신 무엇을 잃고 있는지 인식하고 있는가?

앞으로의 개발자는 코드를 많이 치는 사람이 아닐 가능성이 크다.

대신 AI가 만들어낸 선택지를 판단하고, 책임질 수 있는 사람이 살아남을 것이다.

피곤해졌다면, 그건 네가 뒤처져서가 아니다.
개발의 무게중심이 이동하고 있기 때문이다.

그리고 그 변화의 한가운데에, 지금 우리가 서 있다.